feat(updater): inject bundle_type into endpoint url #2960
Conversation
Package Changes Through b94f5ddThere are 2 changes which include updater with minor, updater-js with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
|
btw those schema changes are because i'm on windows. seems like we updated some dependency in the last few weeks? |
plugins/updater/src/updater.rs
Outdated
| if let Some(installer) = installer_for_bundle_type(bundle_type()) { | ||
| url = url | ||
| .replace("%7B%7Bbundle_type%7D%7D", installer.name()) | ||
| .replace("{{bundle_type}}", installer.name()); | ||
| } |
There was a problem hiding this comment.
Wouldn't this produce URLs with the placeholder still in it when the installer is None?
Say there's an endpoint like:
https://foo.example/update/my-app/{{target}}-{{arch}}/{{current_version}}?bundle_type={{bundle_type}}
Wouldn't that end up as:
https://foo.example/update/my-app/linux-x86_64/1.2.3?bundle_type={{bundle_type}}
There was a problem hiding this comment.
yep. any suggestions? Should we replace that with unknown ?
There was a problem hiding this comment.
using unknown is fine - though this should only happen in dev mode right? or if you run the target/release/app binary directly
There was a problem hiding this comment.
(and i raised this concern before, but we should avoid using unknowns ever - maybe use a default value in that case)
There was a problem hiding this comment.
using unknown is fine - though this should only happen in dev mode right? or if you run the target/release/app binary directly
Yes, if the dev uses the tauri cli to package the app this should never be unknown. If they're using their own packaging system it'll show unknown (or the last created installer)
There was a problem hiding this comment.
(and i raised this concern before, but we should avoid using unknowns ever - maybe use a default value in that case)
not sure i get what you mean. any kind of default value we set (assuming default means one of the existing types?) has a high chance to be incorrect.
There was a problem hiding this comment.
yep. any suggestions? Should we replace that with unknown ?
Having pulled the last of my hair out over Helm charts. The reasons this gets tricky is string templating.
To handle nullable values it pushes you down the route of conditional rendering or default values, and it's not fun 😬
So my first suggestion would be, think about alternatives that support nulls easily.
Like a header with these values in JSON.
As for {{bundle_type}}. I do think unknown would make it slightly more useful than say empty string because then you can use it in paths as well as query strings.
There was a problem hiding this comment.
Another option could be we we don't support this as a {{bundle_type}} placeholder and instead only support this through the query string. Because we then can assume how query strings work, we can omit it when None.
So it's either:
https://foo.example/update/my-app/linux-x86_64/1.2.3https://foo.example/update/my-app/linux-x86_64/1.2.3?bundle_type=appimage
|
agreed, though i do like the Headers idea but that's something for another PR. |
follow up to #2624